Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Health Worker Registry

The health worker registry is the authoritative list of people who provide care, with a permanent identifier for each. It answers who did this, were they qualified to, and where are they posted?

It is the third of the OpenHIE core registries and the one most often deferred, because the immediate benefit is less obvious than a facility list. The benefit appears as soon as anything needs attribution or authorisation.

Why it matters architecturally​

NeedWhat the registry provides
AttributionWhich clinician made this assertion — a legal and clinical-safety requirement, not a nicety
AuthorisationA role in the registry is the input to access control; see identity and security
ReferralDirecting a referral to a named provider, not just a facility
Workforce planningActual distribution of cadres against population and facility
Payroll and payment integrityDetecting ghost workers, duplicate postings, and expired licences
Continuing educationTracking training against the people who received it
RegulationVerifying that the person prescribing is licensed to prescribe

The last point is the one that converts the registry from an administrative asset into a safety control.

Two things that are often conflated​

  ┌──────────────────────────┐        ┌───────────────────────────────┐
  │  Practitioner            │        │  PractitionerRole             │
  │  the person              │  1  ─▶ n │  a posting                    │
  │  · identifier            │        │  · organisation / facility    │
  │  · name                  │        │  · role / cadre               │
  │  · qualifications        │        │  · specialty                  │
  │  · licences + expiry     │        │  · period (from / to)         │
  │  · contact               │        │  · employment type            │
  └──────────────────────────┘        └───────────────────────────────┘

A person is one record for life. Their postings are many records over time, and a person can hold more than one simultaneously — a doctor working in a public hospital in the morning and a private clinic in the afternoon is the normal case, not an edge case.

Systems that model "health worker at facility X" as a single flat record cannot represent transfers, dual practice or historical attribution, and cannot answer "who was working here when this happened?"

The FHIR split into Practitioner and PractitionerRole exists precisely for this, and following it saves a rewrite.

What it holds​

Person-level:

  • Permanent identifier, namespaced
  • Name, including previous names
  • Date of birth and sex, for disambiguation
  • National identifier, where lawful and available
  • Cadre / profession
  • Qualifications: award, institution, date
  • Licence or registration number, issuing council, status and expiry
  • Contact details

Posting-level:

  • Facility (facility registry identifier)
  • Role and specialty
  • Employment type — permanent, contract, volunteer, seconded
  • Period, with an end date when it ends
  • Scope of practice, where the regulatory regime defines one

Not held: performance appraisals, salary, disciplinary detail. Those belong to human resource systems, linked by identifier. A registry that accumulates sensitive employment data acquires an access-control problem that prevents it from being the widely readable service the architecture needs.

Where the data comes from​

This is the hard part, and it is organisational rather than technical. The data is spread across bodies that do not usually share:

SourceHoldsProblem
Professional councilsLicensure and qualificationOften per-profession, separately governed, sometimes paper
Ministry human resources / payrollPostings and employmentOptimised for payment, not for identity
Training institutionsGraduatesRarely connected to anything
Facility recordsWho actually works thereMost accurate, least systematised
Private sector employersPrivate-sector workforceFrequently outside any national system

The registry's value comes from reconciling these. That means it needs a mandate, not just an API. Councils will not surrender authority over licensure data; the workable design is federation of authority with centralisation of identity — the registry holds the identifier and the current status, and each council remains the source of truth for its own licensure records.

Licence status is time-varying and safety-critical​

A licence that expired last month must be visible as expired today, not at the next annual sync. Design:

  • Effective periods on every qualification and licence
  • A status field with a controlled vocabulary — active, expired, suspended, revoked, provisional
  • A change feed so that dependent systems learn of a suspension quickly
  • A policy for what a dependent system does when the registry is unreachable — fail open (allow, log) or fail closed (block)? For prescribing authority this is a clinical safety decision that must be made explicitly.

Registry identity and login identity​

They are different, and confusing them causes real problems.

  • The registry identifier identifies the person professionally and permanently. It appears in clinical records as the author.
  • The login identity authenticates a user to a specific system, and is managed by an identity provider such as Keycloak.

The link between them is an attribute on the login identity — the registry identifier as a claim in the token. That way a clinician who changes employer, email address and username still has a continuous professional identity, and their historical records remain attributable.

See OAuth and OpenID Connect.

Consequence for point-of-service systems: every clinical record should carry the registry identifier, not a local username. This belongs in procurement requirements.

Community health workers​

Frequently excluded, and the exclusion undermines the registry.

CHWs may be volunteers, may not be licensed by any council, may be paid by a non-governmental organisation, and may serve a community rather than a facility. But they generate a large share of the data in primary care systems, they make referrals, and their work needs attribution.

Include them, with:

  • A cadre value for CHW, and sub-cadres if the programme distinguishes them
  • Association with a community unit or catchment rather than only a facility
  • Supervisor relationships, since supervision structure is how CHW programmes actually operate
  • Training records in place of licensure

See community health.

Getting started​

  1. Pick one cadre with an existing, reasonably clean list — often nurses or doctors from a council register
  2. Assign permanent identifiers and publish the namespace
  3. Reconcile against payroll to find ghost workers and unposted staff; the discrepancy list is usually what secures the mandate to continue
  4. Expose a read API and a bulk snapshot
  5. Require the identifier in one high-value system — usually the EMR's author field
  6. Add cadres and private-sector workers incrementally

Step 3 is what makes this fundable. A workforce registry that identifies payroll discrepancies pays for itself in a way that "improved data quality" never does in a budget submission.

Standards and tooling​

  • FHIR — Practitioner, PractitionerRole, Organization, Location
  • iHRIS — open-source human resources information system for health, designed for exactly this purpose; Tier 2
  • DHIS2 — sometimes used to hold workforce data; workable for aggregate workforce statistics, weak as an identity registry
  • HR-XML / national civil service standards — where payroll integration is required

References​

Last updated on